AmigActive 25/AACD 25.iso/AACD/Programming/yaec/docs/positron.txt

Text File | 2001-08-12 | 14.3 KB | 641 lines

Positron (e+) is the name of this extended E language that YAEC compiles.
_________________________________________________________________


Positron adds some new simple types :

ANY, LONG, FLOAT

Okey, LONG is not exactly new.. but now it really acts as a LONG, that is,
it can not be a ptr.

FLOAT  --  32bit single-precision IEEE float.

Maybe the most important type : ANY.
Without it, not many old e-sources would compile.
But its not only for backwards compability either.

How to define a varible as ANY :

DEF x, y:ANY  -> x and y are both of type ANY.

ANY  --  32bit untyped.
ANY can be indexed as a PTR TO CHAR for backwards compability.

Ptr/array types :

There is also PTR TO ANY, ARRAY OF ANY as well as PTR TO FLOAT, ARRAY OF FLOAT.

PTR TO STRING, PTR TO LIST.
Theese last two behaves like beeing a STRING,LIST but is not allocated.
You may use NEW for that : NEW strptr[size]
and END : END strptr
same for listptrs.
String(), List() is also okey to use.

That was a quick ride threw the types.



Type conflicts
**************

-> this will be compiled okey
ng:=[140, (20+topborder), 200, 12, '_Volume:   ', topaz80,
       MYGAD_SLIDER, NG_HIGHLABEL, vi, 0]:newgadget

-> but not this
ng:=[140, (20+topborder), 200, 12, '_Volume:   ', 123.123 ->topaz80,
       MYGAD_SLIDER, NG_HIGHLABEL, vi, 0]:newgadget
-> we replaced "topaz80" (PTR TO textattr)
-> with "123.123" (FLOAT)
-> theese type are not compatible and You will get a "type conflict".



Typed copy (assignment)
***********************

array := array2  -> this actually copies conents of "array2" into "array" !!

array := any -> as "any" _may_ be an array, (the compiler can not now for sure that it is _not_)
                   -> conents pointed to by "any" will be copied into "array".

How did the compiler now how much to copy ?
It did not get it from "any", no size declared there.
It got it from the declaration of "array" !

DEF array[100]:ARRAY OF CHAR

100 bytes would be copied in this case.

DEF array2[200]:ARRAY OF CHAR

still 100 bytes would be copied. there can never be any mem-overwrite.

any := array2
-> this would just make "any" point to "array2", its the only logical thing to do.

Okey, what if using different types ?

string := ptr_to_long  -> this gives type error message.

But this would be okey :

string := ptr_to_char  -> this actually equals "StrCopy(string, ptr_to_char)"

the other way around would the again just copy a ptr :

ptr_to_char := string -> "ptr_to_char" now points to "string".


THE LEFTMOST VARIABLE ALWAYS DENOTES HOW ASSIGNMENT SHOULD BE DONE.

THE RIGHTMOST EXPRESSION JUST HAVE TO BE OF A COMPATIBLE TYPE.

"ANY" IS TYPELESS AND CAN SUBSTITUTE FOR ANY OTHER TYPE.

typed copy also works with object.members :
obj.array := array

An Example:
---------------------------------------------
DEF array[100]:ARRAY OF INT

PROC main()
   array := bla()
ENDPROC

PROC bla()
   DEF array[100]:ARRAY OF INT
   <fill array with values>
ENDPROC array
----------------------------------------------

Here we used arrays as they where like any other values.


YAEC comes with typed internal functions.
************************************************

ex :

StrCopy(s:PTR TO STRING, s2:PTR TO CHAR, len=ALL:LONG) (PTR TO STRING)

This would make compiler complain :
DEF x:PTR TO LONG,y:LONG,z
StrCopy(x, y, z)

both "x" and "y" are of incompatible types.

This on the other hand :

DEF x,y,z
StrCopy(x,y,z)

is okey, cos the compiler can not be sure its NOT.

Better way to do it :
DEF x[100]:STRING, z=10:LONG
StrCopy(x, 'hello there!', z)


So its best to try use typed variables where possible, else dont type em.

To turn off the typechecking, use "TCL -1" on the commandline.


Cloning with NEW
*******************

NEW can be used to "clone" variables :

DEF array[100]:ARRAY OF LONG, copy, string[100]:STRING

<fill array with values>

copy := NEW array

<put text in string>

copy := NEW string

-> "copy" now is an _exact_ copy of "string". _including_ maxlen and all that stuff.

NEW may as usual raise "MEM" if failing to allocate.

This works for objects too.

Another way to clone a string or list :

clone := CloneStr(stringptr)

clone := CloneList(listptr)

This time, only current length is allocated. (maxlen is not preserved).


New preprocessor keywords, features
*****************************************

"OPT PREPROCESS" not needed.

Conditional compilation :
#else keyword

Macros:
#macro keyword

#macro supports varargs, types,... kicks ass :)

Better have a look at for example exec.e and amigalib.e
to see how this keyword works.

#define keyword

Should not be used for expression-substitution anymore, use #macro for that.
Still around for conditional compilation, typedefs,etc.. misc stuff.

IMPORT #define <name>  -> now what is this ??? :)

Imports an #define, defined in main-source, into a module.
Can only be used in modules. (beta thingy)

#undef keyword   -> undo a #define


Classes without using NEW
*****************************

Classes (OBJECTs with methods) may now be allocated by simply
typing something like :

DEF o:classobject

Locally or globally.

At procedure/program end, an automatic "END o" is performed on the classobject.
(including calling .end() method)

example :

PROC bla(x)
   DEF o:object
ENDPROC o.method(x)


CONST keyword extended
*****************************

Float constants :

CONST FLOATVAL=0.1263

Constant labels knows their type, for example, this would not slip
threw type-system :

CONST AAA=10,
      BBB=10.12345,
      CCC=AAA+BBB -> type error!

 not his either :

x := Max(AAA, BBB) -> type error, "BBB" is not integer.


To make them OK :

CONST AAA=10,
            BBB=10.12345,
            CCC=AAA!+BBB  -> CCC= 20.12345

x := Max(AAA, !BBB!)

Finally, "<<" and ">>" is allowed in constant expressions.
(shift left, shift right)


DATA keyword
****************

Data constants : (or : constant data pointers)

DATA MYLIST=[1,2,'hello',-0.9], MYARRAY=[1,2,3,4]:INT,
     MYSTRING='hello there'


Next Gen Unification  (to be implemented..)
********************

This is nothing like the next-to-useless unification-mode
found in old EC...

This is POWER ! :)

First type -> List-unification :

Compatible with EC list-unification.

exp <=> [1,2,x,y,BLA,[1,2,3]]  -> this is legal in EC and YAEC

exp <=> [123,*, x, obj.memb, BLA]
-> *=matches anything.
-> objectmembers can also be used as variables.
-> note : unification takes advantage of typed copy...!!

exp <=> [<2, <>NIL, x, y, <=BLA, *, 10]
-> think about this one for a while.. :)

it gets even worse..
:)

exp <=> [<2|>10, *, x]
-> |=OR

Second type -> object-unification :

As objects data is referenced by names, it makes sense to
have a little different syntax for object-unification so that
the data can still be referenced by name.

object <=> .memb1=NIL, x:=.memb4, .memb2<100|.method1(10)>1000
-> note that there are no brackets here.
-> methods can be used too, as seen above!
-> if the comparisons match, then "x" gets the value of object.memb4
-> "object" must be a variable declared as :object or PTR TO object.
-> got it ? :)

Third type -> string-unification :

This will be very handy for stringmanipulating programs, for
example compilers :)

exp <=> '<TAG>' + s + '</TAG>'
-> very simple, but so extremely effective.
-> If '<TAG>' and '</TAG>' is found in "exp"
-> then copy everything between into estring "s".
-> this equals roughly this code :
match:=FALSE
t := exp
pos := InStr(t, '<TAG>')
IF pos <> -1
   t := t + pos + STRLEN
   pos := InStr(t, '</TAG>')
   IF pos <> -1
      StrCopy(s, t, pos)
      match := TRUE
   ENDIF
ENDIF
-> but more efficient...


-> "+" can also be used by list-unification :

[1,2,3,4,5,6,7,8,9,10,11,12,13] <=> [1,2,3] + x + [10,11,12]
-> this will, if both above static lists are found (in order),
-> copy all between them into list "x".
-> in this case [4,5,6,7,8,9]

List,object and string-unifications can be combined,
in almost any ways :)


Lisp-cells
**********

Say goodbye.... :) I have NEVER had any use of lisp-cells..


Sharing globals
****************

All globals that is to be shared between different
modules, MUST be declared in main-program and then
IMPORTed into modules that uses them.
For backwards compability, EXPORT DEF ... is still
legal. (but does the same as IMPORT DEF ...).


Asm support
************

YAEC supports asm in a different way compared to EC.
First off, it is not integrated into the language.
This makes little sense for portability.

To insert a single line of asm :

ASM ' move.l d0, (a0)+'

To insert multiple lines of asm :

ASM
  dc.l 0
.label
  move.l d0, a0
 ...
 ...
 ...
ENDASM

Asm-code is not touched or checked in any way by YAEC.
This is up to the assembler, currently PhxAss.

To pass values between asm and E, YAEC can use
registers D0-D7/A0-A7 as variables :

ex:

x := A0
D0 := blah()

You should not use registers D2-D7/A2-A5/A7 without
saving/restoring them.


List`N`Quote-functions
**************************

   Slight API-change here.
   same function, and some more.

   bool       := ForAll(list, qexp, qexp2=NIL)
   bool, pos  := Exists(list, qexp, qexp2=NIL)
   listvar    := MapList(list, listvar, qexp)
   listvarlen := SelectList(list, listvar, qexp)

   Now. what happened to the {var} ?
   Here it is : \x (and \y).

   In the above functions \x gives the
   listitem and \y gives the listposition.

   qexp2 in ForAll() and Exists() will,
   if <> NIL be evaluated IF the result
   is TRUE. Then the result of qexp2 will
   be returned instead.

   ex1 :

   Exists(list, `\x=14, `PrintF('yes, at pos \d\n', \y))

   ex2 : (slightly edited example from e.guide)

PROC main()
  DEF mem[4]:LIST,x
  MapList([200,80,10,2500],mem,`AllocVec(\x,0))              -> alloc some
  WriteF(IF ForAll(mem,`\x) THEN 'Yes!\n' ELSE 'No!\n')        -> suxxes ?
  ForAll(mem,`IF \x THEN FreeVec(\x) ELSE NIL)     -> free only those <>NIL
ENDPROC

   Theese functions can be nested!


Unary operators
****************

   ++/--

   The ++/-- operators works a bit more intelligent in YAEC.
   In some cases though, this may break things.
   In ec3.3a theese operators always affects the base-variable.
   In YAEC ++/-- always affects the latest dereferenced `variable`.

   YAEC ex:
      var++ -> affects var (as before)
      var[]++ -> affects var (as before)
      obj.member-- -> affects member !
      self.member[]++ -> affects member !
      obj.optr.member[]-- -> affects member !

   Especially when referencing self.xxx variables this will
   be very handy. Instead of typing "self.ptr := self.ptr + SIZEOF LONG",
   just type "self.ptr++" (if self.ptr is a PTR TO LONG :)).

   In other words : member or variable, same function.


   ^ : This operator is not supported at the moment.

       Better is to use indexing ([]) or the Long() function to peek
       into memory.

       [this operator is marked as obsolete in the ec3.3a E.guide]


Removed keywords
*****************

   o INC, DEC

      use ++ -- instead.

   o VOID

      VOID ? Anyone used it ? :)
   YAEC18+ : This keyword may now be used for types.


Removed functions
******************

   o CleanUp()   (use exceptions instead)

   o Gadget()

Jumping around  --    JUMP, LAB
*******************************

   Theese keywords works locally to procedures.

   JUMP works like in ec.

   LAB is used to define a label.

   Ex:

   IF a THEN JUMP mylabel
   ...
   ...
   LAB mylabel
   ...
   ...

   The nice thing about local labels in yaec is that they are
   local... :) i.e. The same labels can be defined in several different
   procedures without conflicts.


Class variables
****************

This is an idea, but Im not sure if Ill implement it.
What are they good for ?
It is variables that all object of one class (and subclasses)
have in common, they share them. In a language like Java,
I can imagine it is very useful, because there are no globals
(I think), but everything is wrapped in classes/objects.
In E we got the module concept...
As I can understand, there is not much difference declaring
some gloals private in a module and declaring them private
to a class in a module... ??
So this is still pending..


Anycase keywords
****************

This may be a HOT issue.
Im seriously considering allowing keywords to be in lowercase too.
I suspect a lot of people gets scared away by the big screaming keywords.. :)
I know I was in the beginning. And from some looks at lowercase
E sources, it kinda looks pretty nice, very soft.
We`ll see in the future.


Typed procedures/methods
************************

The syntax for this is inspired from PowerD (Martin Kouchinka)

ex:

PROC bla(x,y) (LONG) ...

Tells that this procedure/method returns ONE value
which is of the type LONG.

If a function does not return anything, "VOID" may be used :

PROC compute(a,b) (VOID) ...


now this is an error (compiler will complain) :

x := compute(a,b)


If omitting the optional type-info (like in AmigaE), the procedure/method
is considered as returning (ANY,ANY,ANY).


Method-dereferencing
********************

Methods may now be dereferenced just as members!

object.method().member[].value .. etc..

For this to work, the method must be typed,
and ofcource as returning some kind of object !

Ptr-typeing also works :

x := object.bla()::window.rport

for now, this ptr-typeing is not smart enough
to react if .bla() returns a CHAR or INT...


Dynamic typed lists (to be implemented..)
or Complex types assignment
or Stream Assign or similar :)
*******************


[1,2,3,x,y]>>l

equals :

l[0] := 1
l[1] := 2
l[2] := 3
l[3] := x
l[4] := y

"l" may be any LIST/ARRAY/PTR/OBJECT

bla(100,200,[1,2,3,x,y]>>l)
-> list passed is not static!
-> using lists like this in librarymode, keeps the lists reentrant.

NEW [1,2,3,x,y]>>l
-> this first does a "NEW l",
-> then assigns values to "l".


x := [1,2,*,*,y]>>l

equals:

l[0] := 1
l[2] := 2
l[5] := y
x := l

-- Following two only with "l"=PTR --

x := [1,2,*,a]>>l++

equals :

l[]++ := 1
l[]++ := 2
l++
l[]++ := a
x := l


x := [1,2,*,a]>>l--

equals :

l[]-- := 1
l[]-- := 2
l--
l[]-- := a
x := l